【渲染篇】新时代的SRP Batcher 和尴尬的Dynamic Batching

本系列基于：BDFramework 、Unity3D 2019.4

BDFramework：Simple! Easy! Beautiful! This is a powerful Unity3d game workflow!

框架地址：

GayHub: yimengfan/BDFramework.Core，

码云 ： yimengfan/BDFramework.Core，欢迎赏星。

第九艺术 、第十艺术讨论群 : 763141410

搜索关键字：Unity3d Draw call，Dynamic Batching，Srp Batcher

前言水文（可直接跳到正文）：

没想到吧，沉寂了半年的我又回来了！！！

这半年主要太忙了，公司有项目，私下还在做一个项目，然后还要维护框架，各种杂事..

其实我一直再写，但是写文章很费时间的，写不出很好的我就不发了，写文章考虑文风、表达、整理，写一篇文章大概需要耗费我一上午的时间。（然后我一想，半天，还不如做做自己的项目没准还能赚钱小钱，再过4年就30了，只能想办法先挣钱先。。。跪着）

最主要还是题材，讲简单了太水不够装逼（比如字符串拼接啊，xxx怎么使用啊），讲复杂了又没人看，但是录视屏也就30min完事，但是也没啥人看。直到最近知乎呼唤我，我才知道我存稿那么多...

好了不水了，进入正文...

最近半年我们用URP 下面的2d管线做项目，坑是真的坑，香也是真的香~~

0x001 阅前小姿势：

首先，枯燥的开始老生常谈的话题 ：Draw Call，我们来同步下大家的阅读前知识 :

1.Unity 有3个降低Draw Call的方式：Static Batching，Dynamic Batching，Instancing

2.为什么要降低Draw Call？Draw Call的消耗点在哪？

这里简单讲下，后面细讲。

简单来说DC高了会增加Cpu的消耗，手机上CPU和GPU是共享一个SOC，无论哪个消耗高了，温度增加，都会导致一起降频，就是卡！

对于unity来说，主要在SetPass Call这个参数上体现,并不是Batches。主要消耗在SetPass Call环节上。

好，打住，再细说就变成科普 draw call的环节了 那就太low了....

0x010：新时代的SRP Batcher

先简单说说SRP、URP、HDRP，很多人对着三个名字有点混，特别SRP和URP，还有Unity搞得UPR：

SRP是Unity的可编程渲染管线，URP 和 HDRP 是在此之上具体的2个实现！

其实也不存在什么一个只能在手机上，一个只能在pc上，其实都能在手机上跑， 各自根据自己项目可以调节，哪些流程不需要，哪些流程加点什么处理....

好，我们再说SRP Batcher：

进入新管线设置后有下面选项

然后，这里片文章，讲的挺不错的，我就不重复去讲了。

顺便盗里面的图，忽略下面的叠杀人书。。。

我们看下两个流程的区别：

简单来说SRP Batcher是，提前把各种数据丢到CBuffer里面去，这样你DC的环节就少了很多，直接去CBuffer里面找就是的。

再简单一点就是： SRP Bacher 不减少DC，只是减少每次DC的消耗...

直观感受是：

传统管线 ： 低端机 200 Setpass call，250 Batches。 卡！！！！

SRP ： 低端机 200 SetPass call，1000 Batches 。没上面卡~~

说的夸张点就是（比较狭义，别大规模宣传，会丢人）：

只要你是同一个Shader（注意考虑变体情况），都能自动合批！

（这里的合批是形容词，不是动词）

这么一说，可能你就感觉到SRP Batcher的作用了。

这么一想，我们是不是再没必要做Dynamic Batching了？

再聊聊Dynamic Batching。

0x011：尴尬的Dynamic Batching

这里不是为了捧SRP Batcher 才说他尴尬，而是说Dynamic Batching本身就很尴尬~

我们回想下为什么要Dynamic Batching？
减少DC！
为什么减少DC？
减少CPU消耗！

好了问题来了，那么Dynamic Batching是怎么回事，引擎不写功能，管线又不会自动给你合批。

如果你了解过场景管理、OSG之类的，可能很快能理解：

整个Dynamic Batching 都是引擎帮你按一定规则（经验），去算出来的！

那你想想整个场景上的东西那么多，要是把能合批的都合批了，那得计算量多大？

所以Unity就给了一堆限制，在之上进行合批的计算，减少Cpu消耗。。。

有个热心网友，给你统计过了20多条。

所以你能理解，为什么要有这么多限制了吧？

在这些限制之下，能减少合批的计算，再想想，合批之下哪些模块最容易符合这些要求？

UI，没错，UI仔你们又可以沸腾了！到了你们的专场！

再想想为啥有那么诡异的UI合批规则，比如图片重叠打断合批等。。。。

再想想Mesh Rebuild怎么回事？

再想想UI 本质是怎么回事？

这下都通了吧！这下都通了吧！这下都通了吧！

好的 打住，再收回来：

我们想想 Dynamic Batching为什么尴尬？

因为减少DC是为了减少CPU消耗，而合批计算又需要消耗CPU！

因为减少DC是为了减少CPU消耗，而合批计算又需要消耗CPU！

因为减少DC是为了减少CPU消耗，而合批计算又需要消耗CPU！

当然，这在一些情况下是有用的，比如UI，（但是也不一定，具体取决于合批的计算消耗，比如跨的mesh太大了）。

但是你在游戏场景中做的动态合批，大概率都是无效的~~ 只是看到的数字下降了而已。

所以dynamic batching本身是有点尴尬的，算力换算力~

能静态绑定的就静态绑定吧，别偷懒。。。

据小道消息，Unity不久后会干掉Dynamic Batching...

结束语：

你问我项目要不要切换到SRP下？

我个人觉得中小团队，性能上没啥瓶颈，就别折腾了！！！！

赶紧上线最重要！！

因为新技术没啥积累。这些积累，都是你们团队要付出的成本代价。

再加上，现在手机比我几年前 电脑配置还nb，先上线，先跪着把钱挣了吧！

什么？你想站着把钱挣了？

我们团队在招人，联系我吧~~

没错，这是一篇招聘广告。。。。。